In a second Generation (2G) or third Generation (3G) mobile communication system, MSC is an important node of core network for controlling the mobility management and various call services in the circuit domain. The steady operation of MSC device reflects the reliability of the whole mobile network. Along with the rapid development of mobile communication network, the capacity of MSC keeps rising. Especially under the 3G R4 architecture, the MSC is divided into an MSC Server and a Media Gateway (MGW). One MSC Server may manage multiple MGWs. The range controlled and the user capacity supported by each MSC Server greatly exceed those supported by the MSC of 2G system. Therefore, the reliability and the disaster recovery requirement of MSC are particularly important.
There is no disaster recovery solution provided for the MSC in the existing 2G network. When an MSC fails in the network, the services within the administration range of MSC are all interrupted until the MSC is recovered. The 3rd Generation Partnership Project (3GPP) standard organization provides an Iu-Flex solution for the disaster recovery of core network side in R5 version including: improving the reliability of the whole system by the access network connecting with multiple core network entities such as MSC and Service GPRS Supporting node (SGSN).
With reference to FIG. 1, 3GPP standard TS23.236 proposes a concept of pool area, i.e. forming the areas covered by several Radio Access Network (RAN) nodes such as Radio Network Controllers (RNC) or Base Station Controllers (BSC) into a pool area. Services of the pool area are generally provided by several core network nodes such as MSC or SGSN in parallel. For example, as shown in FIG. 1, MSC 1, MSC 2 and MSC 3 simultaneously manage pool area 1 formed by Area 1, Area 2, Area 5 and Area 6; MSC 4, MSC 5 and MSC 6 simultaneously manage pool area 2 formed by Area 2, Area 3, Area 6 and Area 7. To identify a core network node, each core network node is allocated with one or several Network Resource Identity (NRI). When a mobile terminal establishes a Non Access Stratum (NAS) connection with a core network node, a RAN node routes the initial NAS message to the core network node corresponding to the NRI according to the NRI carried by the initial NAS message. By taking pool area 1 as an example, each of the RANs within the pool area connects with MSC 1, MSC 2 and MSC 3 simultaneously; if any of them fails, the access network cancels the route of the failed MSC, and distributes the newly initiated traffic to other MSCs. Therefore, the disaster recovery is implemented.
However, the disaster recovery solution as shown in FIG. 1 has the following problems in practical applications.
Implementation is complex. The solution as shown in FIG. 1 is a full-network solution in which the core network entity such as MSC and SGSN and the access network entity such as RNC and BSC need to be modified; especially at the MSC side, it has great impact on the location update and handover procedure due to the introduced new concept of NRI and pool area; it is needed to not only take the service condition under the Iu-Flex node within the pool area into consideration, but also to take the interaction and compatibility between pool areas and non-Iu-Flex nodes into consideration, which greatly increase the complexity of core network side service logic.
The implementation is difficult in a 2G network such as GSM. The Iu-Flex technology is introduced in 3GPP R5, and can not be supported by the BSC device of 2G network; if the BSC device of 2G network supports the Iu-Flex technology, it is needed to perform a great deal of upgrade operation, which is difficult for the development in the GSM network.
The network topology is complex. In the Iu-Flex solution, an access network entity establishes connections with multiple core network entities, which increases the complexity of network topology and is difficult for operation maintenance.
There is a defect in the called service after the MSC Server fails. With reference to FIG. 2, under the Iu-Flex networking as shown in FIG. 2, after MSC Server 1 fails, if a user who originally registered under the Visitor Location Register (VLR) corresponding to MSC Server 1 does not initiate the location update procedure or the calling service procedure, this user can not be successfully called because the VLR address of this user recorded in the Home Location Register (HLR) is the VLR address of MSC Server 1.
The MGW resource is unavailable when the MSC Server fails. With reference to FIG. 2, when MSC Server 1 fails, the user plane resource of all MGWs administrated by MSC Server 1 is in idle state and can not be used. This problem is more outstanding when the range administrated by the MSC Server is large, because various voice processing resources for TC, EC and MPTY bridge provided by the MGW are all valuable; resource sharing and effective load sharing are difficult to be achieved when the networking architecture is as shown in FIG. 2.